Hacking en redes conmutadas 


Angel Alonso Párrizas 
parrizas@wanadoo.es 
http://angelillo.no-ip.org 


Introducción 


El uso de conmutadores es seguro frente a sniffers 
No en todos los casos todos los conmutadores son la panacea 
Veremos como se puede capturar tráfico en una red ethernet conmutada. 
¿Qué soluciones hay? 

Otros ataques. Ejemplos de sniffers 
¿Cómo podemos detectar estos ataques? 

Bibliografía y referencia web. 

Conclusiones 
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Nuestro escenario 1 


Red en casa de cultura dependiente del consistorio municipal. 

PC dirección casa de cultura. 

PC oficina de turismo. 

8 PCs ubicados en la bilioteca. Libre acceso a Internet. No instalar 
software. 

2 PC's consulta biblioteca, videoteca, Cdteca, DVD's 

1 PC Bibliotecario para altas/bajas. 

2 puestos libres para portátiles. 

Conmutador LAN ovislink Ether-FSH24RS con 24 puertos 10/100. 

(http://www.ovislinkcorp.es/productos/producto.php?categoría=switch&id=ll) 

Router ADSL 3com 812 con línea de 2Mbits/s. 


Nuestro escenario 2 

Servidor Linux (Debian 3.0) 

DNS, Bind9. Se tiene un dominio registrado. 

DHCP. Parar asignar las ip's de todas las máquinas de la red local. 

Exim. Gestión del correo con el nombre de dominio adquirido. 

Apache. Ver: 1.3.27. Páginas web del ayuntamiento y biblioteca. 

MySQL. Base de datos de libros y usuarios (120Megabytes). Algunas 
webs interactúan mediante PHP. 

Telnet: Administración del servidor. 

Núcleo 2.4.18-bf4 (por defecto la que trae la distribución). 

Iptables. Hacemos NAT a la red local y filtramos tráfico como P2P. 


Nuestro escenario 3 


La red siempre ha funcionado bien, exceptuando las veces que se cae el 
ADSL. 

...hasta que un día y en momentos concretos el acceso a la base de datos 
era imposible.. 

Comprobamos autonegociación y forzamos manual 

root@ servidor: ~$ mii-tool 
ethl: 100 Mbit, Full dúplex, link ok 

El problema no era éste, porque sólo ocurría en momentos muy 
concretos. Cuando los usuarios de portátiles se conectaban. 

. ¿Problema de DHCP y conflicto de IP's? 

Un usuario en concreto usaba una aplicación desconocida para nosotros. 

Ettercap 


¿Que es ettercap? 


Sniffer que funciona bajo un ataque llamado ARP-poison (envenenamiento 
ARP) 

El ataque arpovecha el protocolo ARP (Address Resolution Protocol) 

ARP nos devuelve la MAC de una tarjeta que tiene una dirección IP. 

Se envía un paquete ARP a la dirección broadcast FF:FF:FF:FF:FF:FF 

Pero cada máquina guarda en su caché el par MAC/IP durante un 
tiempo. 

Aunque no efectuemos un ARP-Request en nuestra caché se guardan los 
datos igual. 

Fo que hacemos es falsear ARP con la MAC del atacante de modo que el 
tráfico pasa por el ordenador espía. 


Funcionamiento ARP 




H1 envía un paquete ARP-Request a la dirección broadcast 
preguntando cual es la MAC de la tarjeta que tiene como ip 



H1 anota en su caché que la MAC 00:00:00:00:00:02 es de la 
máquina con ip 192.168.0.3 

El mismo procedimiento para el host2 


El conmutador recibe tramas por el puerto de H1 con dirección origen MAC del host2. 

El conmutador asocia al interfaz de H1 la MACl. La trama la manda por inundación por 
que no conoce a que interface corresponde. Cuando H2 contesta ya sabe cual es el interface 
por el que lo debe de enviar porque ya lo tiene en sus tablas. Anota el par MAC-puerto para H2. 



Envenenamiento ARP 


Hostl 






Host2 


00:00:00:00:00:03 

192.168.0.3 



EL host -Espía envía a Hostl ARP-Replys 
haciendo creer que el Host2 es él, así todas 
las tramas que vayan al H2 pasan por el host- 
Espía. Para evitar que H1 se de cuenta el H-E 
reenvía a H2 las tramas que ha capturado. 
Además se mandan ARP-Replys 
continuamente para tener la caché 
“engañada.”. Análogamente se hace con H2 
lo mismo, haciendo que el tráfico hacia H1 
pase por HE. 

Al conmutador se le hace creer que por el 
puerto donde está el HE tenemos el H2 
mandándole tramas con las MAC de la 
víctima. 





Nuestro escenario 



IP: 192.168.50 192.168.50.64 

GW: 192.168.0.1 GW: 192. 168.0.1 


192 i*«n7n 

GW:192.168.0.1 



Nuestro host -Espía manda ARP-Replys a todas los host de la 
red haciendo creer que él es el que tiene la MAC 
00:00:00:00:00:01 y como con ésta dirección hardware es la que 
pertenece al router por defecto de todos los host para salir a 
Internet, todo el tráfico pasa por él, captura lo que quiera y reenvía 
a Hl. 

EL problema es que este procesamiento lleva su tiempo y al 
final se ralentiza. 


A nivel de conmutador, éste en sus tablas tiene para dos 
puertos distintos una misma MAC porque el espía ha mandado 
tramas con la MAC 00:00:00:00:00:01 por el puerto donde 
está conectado. Y para el puerto Espía tendría en sus tablas 
dos MAC's, la falsificada y la propia. 



Ettercap 
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Entrando en el servidor 

También se puede inundar las tablas del conmutador con MAC's falsas de tal 
manera que el conmutador no encuentra la dirección destino en sus tablas y 
la manda por broadcasting. 

El Hacker captura sesiones telnet, captura el usuario y password. 

Aunque no accedíamos como root sino con usuario normal y setuidabamos 

(su) el hacker logró explotar una bug del kernel en una función de llamada al 

/ 

sistema ptrace para ver el estado de un proceso hijo. Este bug está presente 

en todos los kernels anteriores a 2.4.21. http://lists.debian.org/debian-security/2003/debian-security- 

200304/msg00 118.htm 

El problema de éste ataque es que permite capturar sesiones encriptadas 
SSH1, SSL, creando certificados falsos. Por ejemplo, H1 y H2 y E(espía) 
capturamos el establecimiento de conexiones de A, a continuación enviamos 
a B un certificado idéntico al de A pero con ip la de la maquina E, al mismo 
tiempo enviamos un certificado falso a A así todo el tráfico pasa sin encriptar 
por E. 


¿Cómo evitarlo? 


La solución óptima es configurar los puerto del conmutador como seguros. 

Se puede asociar a un puerto una o varias MACs para que filtre todas las tramas que 
no lleven en su dirección origen alguna de esas MACs. 

En los switch cisco por ejemplo esto sería algo como: 

Console> (enable) set port security 2/1 enable 

Console> ( enable ) set port security 2/1 enable 00-90-2b-03-34-0 

No todos los conmutadores permiten esto. Cisco si. http://mailman.argo.es/pipermail/hacking/2001- 

September/0006 7 7 . htm l 

Nuestro conmutador no permite ésta configuración. Hay que idear algo. 

Crearemos VLANS en el conmutador aislando el tráfico de las conexiones de 
portátiles 

Añadimos una tarjeta de red al servidor y tenemos dos redes independientes 
Hacemos NAT para las dos redes pero entre ellas no se ven. 


Creando VLANS 


-■nhrr-rMia<Pai ■ ^Yri r I i mini.il 


¡Ffa Ei fe -ÍM\ lrW«r h-’: 






EP cff 


- ^ VtfiH SelL» Meí*-iu *- **»■——* 

Pflrt 01 02 63 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 29 21 22 23 24 
ULAN! V V V V Y V V V V V V V V V 7 V V V V V V V V V 
W.AN2 V 

W.AM3 V V 

UL0N4 V 

Eíiter P&rf 


CimKtrfO(LD!3S |í*Jto dtfKtl: |]93JDM] 




Situación final 

EthO conectada al router ADSL 3com 
Ethl conectada a VLAN 1 192.168.0.1 
Eth2 conectada a VLAN2 192.168.1.1 

VLAN1: conectamos todos los ordenadores de la biblioteca y la casa de cultura 
VLAN2: latiguillos de los portátiles y el cable hacia eth2 

Usamos la aplicación shorewall para hacer NAT y filtrar el tráfico. Iptables también 
permite filtrar por MAC. 

Algo así haríamos si lo hiciéramos a algo 

echo 1 > /proc/sys/net/ipv4/ip_forward 

iptables — flush 

iptables — table nat —flush 

iptables —table nat — append POSTROUTING — out-interface ethO -j MASQUERADE 
iptables —append FORWARD — in-interface ethl -j ACCEPT 
Iptables —append FORWARD —in-interface eth2 -j ACCEPT 

Tenemos dos redes 192.168.0.0 y 192.168.1.0 


Actualizaciones servidor 


Nueva versión del núcleo 2.4.21 libre de bugs. 

Cambiamos el acceso vía shell por ssh2 en vez de telnet. Encriptamos. 

Se desactivaron el acceso a shell a las cuentas que no se usan como tal, 
como la que accede para hacer las búsquedas en la base de datos 
OPAC1. (/bin/false) 


Otros ataques 

MAC Flooding: Inundar el conmutador para que mande las tramas por 
broadcasting. 


MAC duplicating: ponerse la MAC de otra tarjeta así el tráfico también es 
enviado por ese interface. 


Ifconfig ethO down 

Ifconfig ethO hw ether 000000000005 

Ifconfig ethO up 


Ataques de Spanning-Tree: Se envía desde un host BPDU's con el objetivo de 
recalcular el árbol libre de bucles. Consecuencia: Denial Of Service, mientras 
se recalcula el árbol no se retrasmiten tramas. También se puede enviar BPDUs 
con prioridad máxima para que el usuario atacante quede como raíz y vea 
tráfico que no debería ver, para ello el atacante debe estar conectado a dos 
conmutadores a la vez. Todo esto es posible si se tiene software adecuado por 

ejemplo para generar BPDUs. http://usuarios.lycos.es/elvenbyte/index.php?pagina=stp 


Programas alternativos 


ARP-FUN, ARP-TOOL, DNIFF. 

DNIFF: soporta más de 30 protocolos, algunos de ellos estándar y otros 
propietarios. 

-FTP, Telnet, SMTP, HTTP, POP, poppass, NNTP, IMAP, SNMP, 
LDAP, Rlogin,RIP, OSPF, PPTP MS-CHAP, NFS, YP/NIS, 
SOCKS, XI 1, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting 
Maker, Citrix ICA, Symantec pcAnywhere, NAI Sniffer, Microsoft 
SMB, Oracle SQL*Net, Sybase et Microsoft SQL 

Permite capturar sesiones SSL y presentarse certificados ilegítimos 


Otros usos de envenenamiento ARP 


ARP-Spoffing es usado para sistemas de backup y de tolerancia a fallos. 
Mediante IP alias y ARP-Spoofing permitimos que un servidor adopte la 
identidad del servidor que se ha caído. 


Detección de ARP-Spoffing 

Evitar el ARP-Spoffing sin los conmutadores adecuados es muy difícil. 

Hay programas que permiten avisar al administrador de una red de ataques ARP. 
ARPwatch monitoriza los pares MAC/IP y alerta cuando hay un cambio. 

Se debe de monitorizar el tráfico y comparándolo con una base de datos 

Otros programas toman secuencias IP/MAC y periódicamente preguntan las 
actualizaciones en la red. 

Estos métodos resultan farragosos cuando por ejemplo se dispone de un servidor 
DHCP que asigna las IP's dinámicamente 

Otra solución, aparte de comprar un conmutador “100% against sniffing” es hacer 
que los datos vayan encriptados aunque esta medida sobrecargue el procesamiento 
de los datos y añada complejidad en las configuraciones. 


Conclusiones 


Para usar este tipo de ataques no se necesita conocimientos específicos de 
programación. Al alcance cualquiera. 

Existen muchos programas para éste tipo de ataques. 

En situaciones con muchos usuarios, como redes académicas, controlar éste tipo de 
ataques porque permiten ver todo el tráfico de un segmento de red pudiendo permitir 
averiguar información de usuarios, contraseñas, etc. 

No está demás controlar el las tablas MAC/IP para ver si existe algún tipo de 
duplicidad o cambio que puedan inducir a un ataque. 

Siempre se pueden automatizar logs, Scripts, etc., para que manden periódicamente 
información al administrador. 

En última instancia se puede aislar las tramas de una MAC mediante iptables. 

Es importante conocer las características del conmutador antes de comprarlo y ver si 
está preparado para éste tipo de ataques. 



